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Propellant-optimal trajectories, relative sensors and navigation, and docking/capture 
mechanisms are rendezvous disciplines that receive much attention in the technical 
literature. However, other areas must be considered. These include absolute navigation, 
maneuver targeting, attitude control, power generation, software development and 
verification, redundancy management, thermal control, avionics integration, robotics, 
communications, lighting, human factors, crew timeline, procedure development, orbital 
debris risk mitigation, structures, plume impingement, logistics, and in some cases extra- 
vehicular activity. While current and future spaceflight programs will introduce new 
technologies and operations concepts, the complexity of integrating multiple systems on 
multiple spacecraft will remain. The systems integration task may become more difficult 
as increasingly complex software is used to meet current and future automation, 
autonomy, and robotic operation requirements. 


INTRODUCTION 

The Gemini, Apollo, and Space Shuttle Programs have successfully met Rendezvous, Proximity 
Operations, and Docking (RPOD) mission objectives by performing complex integration of spacecraft 
systems commonly recognized as RPOD with those that may not appear to be related to RPOD. The 
Constellation Program faces the same challenge. Systems integration and mission planning to meet 
programmatic and mission objectives occurs throughout the life of a flight program, beginning with the 
initial design effort. Integrated spacecraft systems must permit safe and successful accomplishment of 
mission objectives and be flexible enough to meet current, evolving, and future mission requirements, 
mission objectives, and constraints. The complexity of orbital operations involving multiple spacecraft, 
and a variety of government agencies and contractors, and the amount of effort required to successfully 
perform those operations, is far greater than may be inferred from observing RPOD missions on television. 

As with ascent and entry, RPOD is a complex phase of space flight. RPOD is tightly integrated with many 
vehicle subsystems that work together to provide capabilities required to accomplish rendezvous and 
docking. A vehicle cannot be made RPOD capable by simply adding a sensor or avionics package. RPOD 
complexity is reflected in the various types of missions, chaser vehicles, and target vehicles in NASA’s 
human flight program since 1965. 1,2 RPOD is traditionally viewed as the domain of specialists in orbital 
mechanics, navigation, and hardware capture mechanisms. In reality, it involves complex integration of 
systems both directly and indirectly concerned with RPOD. Each system influences or depends on other 
systems to be successful. Personnel in many non-RPOD spacecraft disciplines are included in the RPOD 
aspects of spacecraft development, mission design, and mission execution (Figure 1). 
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Figure 1 Many systems and spaceflight disciplines directly or indirectly influence 
sub-systems design and operation for the RPOD flight phase. 

This paper covers several areas that are the subject of systems integration for human spacecraft that 
perform RPOD. These areas include: Rendezvous Missions and Phases of Rendezvous; Design, 
Development, Test, and Engineering; Chaser and Target Vehicle Integration; Vehicle Design; Integrating 
Rendezvous and Proximity Operations Systems; Contingency Planning; Applying Lessons Learned to 
RPOD Integration; and Integrated Teams. 


RENDEZVOUS MISSIONS AND PHASES OF RENDEZVOUS 

The complexity and content of the 
rendezvous integration task depends on the 
flight phase and the nature of the mission. 

There are two types of rendezvous missions, 
ground-up and deploy-retrieve. In a ground- 
up rendezvous, a maneuvering spacecraft 
(called the “chaser”) performs a rendezvous 
with a spacecraft (called the “target”) that 
typically does not maneuver (Figure 2). 

Usually the target spacecraft is in orbit 
before the chaser is launched, although the 
launch order could be reversed. Most 
Gemini missions, all Apollo missions to the 
Moon, and many Shuttle missions flew this 
type of rendezvous. 1 

A second type of mission, the deploy- 
retrieve, involves a target spacecraft 
deployment by a chaser spacecraft (Figure 
3). The chaser then separates from the 
deployed target. During the deployed phase 
of the mission the chaser and target 
independently or jointly conduct various 
mission activities while separated by tens of 
miles or more. Once target spacecraft tasks 
have been performed the chaser performs a 
rendezvous and retrieval of the target 
spacecraft. Many shuttle missions flew this 
type of rendezvous. 1 



Figure 2 STS-82 Ground Up Rendezvous Profile 



profile (June 1985). 
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Both ground-up rendezvous and deploy-retrieve rendezvous missions can be divided into three phases. 

Far Field Rendezvous Phase 

For a ground-up rendezvous, the first maneuver in the rendezvous sequence starts at lift-off and continues 
until orbital insertion. At orbit insertion the chaser may be displaced from the target spacecraft by several 
thousand miles and may lap the target before the rendezvous is complete, therefore this phase is often 
generically called the far field rendezvous phase (Figure 2, Insertion through NC3). During the Gemini, 
Apollo, and Space Shuttle Programs, the most accurate navigation state estimates for the chaser and target 
during this phase were computed on the ground. Maneuver targeting was also performed on the ground 
due to limited chaser vehicle on-board computer capacity, hence this phase has traditionally been called the 
“ground-targeted phase.” For example, during Shuttle missions ground-based C-band radar, Tracking and 
Data Relay Satellite System (TDRSS) Doppler, and Global Positioning System (GPS) measurements may 
be used by Mission Control for chaser and target orbit determination, and to compute chaser and possibly 
target orbital adjustments. Due to the presence of GPS absolute navigation and greater computer capacity 
on the Orion vehicle, this phase is known as the “absolute navigation phase” within the Constellation 
Program. Relative navigation using relative sensor data is not performed during the far field phase as the 
range between the chaser and target is larger than the acquisition range of relative sensors. However, 
absolute navigation, maneuver targeting, and bum execution accuracy during the far field phase must be 
sufficient to place the chaser within the relative sensor acquisition envelope for the near field phase. The 
length of the far field phase can vary from a few hours to several days. Deploy/retrieve missions typically 
also have a far field phase as the chaser may separate to a distance outside the range of relative sensors. 
The NCI maneuver in Figure 3 is one example. 

Near Field Rendezvous Phase 


The near field rendezvous phase, also known 
as the on-board targeted or relative 
navigation phase, begins when relative 
navigation sensors on the chaser can acquire 
and track the target (Figure 4). Orbital 
adjustments are computed on-board the 
chaser spacecraft. Maneuver placement and 
timing is designed to facilitate rendezvous 
with the proper relative motion and orbital 
lighting conditions needed for the initiation 
of proximity operations piloting (human or 
automated) in the presence of trajectory 
dispersions. In the event of a primary sensor 
failure, back-up procedures using other 
sensors are executed to ensure a successful 
rendezvous and transition to the proximity 
operations phase. Overlap of the operating 
envelopes of multiple sensors is necessary to 
permit assessments of sensor performance. 



Figure 4 Flight day 3 Space Shuttle rendezvous activities 
up until the proximity operations phase for an ISS mission. 


Proximity Operations Phase 

Proximity operations is considered to begin when trajectory control transitions from discrete bums 
performed at intervals of hours or tens of minutes to near continuous trajectory control based on changes in 
relative motion (Figure 5). Relative sensors continue to provide measurements to on-board relative 
navigation. Automated or human piloting tasks are accomplished using cues from a variety of relative 
navigation sensors. For current Space Shuttle missions the transition to proximity operations occurs at the 
MC4 maneuver, approximately 2,000 feet from the target spacecraft. 

Procedures during this phase can vary depending on the characteristics of the target spacecraft and mission 
requirements, much more so than during the ground targeted and on-board targeted phases. During 
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Space Shuttle Docking with ISS. 



Figure 6 Dale Gardner about to capture 
the Westar-VI (STS-51A, Nov. 1984). 


proximity operations the physical characteristics and systems capabilities of both spacecraft become more 
significant in defining mission requirements, systems requirements, procedures, and constraints on the 
concept of operations. These vehicle characteristics and systems include vehicle attitudes, masses, and 
systems such as thrusters, attitude control, communications, thermal control, and power generation. A 
single anomaly in any one task or system can place the entire mission timeline at risk. The degree of 
coordination required across multiple chaser and target vehicle disciplines is significant. 

If spacecraft servicing or assembly is to be performed, preparations for these activities complicate the 
proximity operations phase. Robotics systems checkout/activation and Extravehicular Mobility Unit 
(EMU, or space suit) checkout/EVA preparation can occur at any time between orbit insertion and 
docking/capture. If the target is to be captured for servicing, robotics activation and/or EMU/EVA 
preparation must occur simultaneously with proximity operations. Manual capture and manipulation of a 
target for berthing by suited EVA crewmembers complicates proximity operations (Figure 6). Unique, 
target- specific hardware must be manually attached to the target spacecraft and used to manipulate it into 
the berthing cradle in the Space Shuttle payload bay. This hardware is designed, tested and certified during 
the pre-flight mission preparation phase, and the target spacecraft may not be available for pre-flight 
mating fit checks. 

Chaser separation from the target occurs after the mated activities are concluded. Proximity operations 
piloting techniques and relative navigation sensors are used to ensure a successful safe separation that 
minimizes the possibility of re- contact and Reaction Control System (RCS) jet plume impingement. 


DESIGN, DEVELOPMENT, TEST AND ENGINEERING 

The success of the Design, Development, Test and Engineering (DDT&E) phase of a flight program 
depends on a clear understanding of programmatic, spacecraft, and system requirements. Personnel on a 
spacecraft development project or a systems upgrade should have a clear understanding of the mission and 
“end goal” of the project. This section discusses examination of requirements and constraints, and the 
advantages and disadvantages of adopting legacy hardware, procedural work-arounds, and simple tools to 
reduce risk during DDT&E. 

Examination of Requirements and Constraints 

During the DDT&E phase, new technology, at an appropriate readiness level, is integrated into a vehicle 
along with selected, flight-proven software algorithms, hardware, and mission operations concepts from 
legacy programs. Export control regulations may restrict choices of sensors and other hardware. 
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Project personnel strive to thoroughly understand the requirements, design, and operation of evolving 
vehicle systems. The integration of legacy and new hardware, software, and mission techniques in all 
vehicle systems must be closely examined to ensure compatibility. This examination includes changes to 
non-RPOD systems for impacts to systems traditionally associated with rendezvous and proximity 
operations. 

Spacecraft system development is continually challenged through competition with other spacecraft 
systems and flight phases, such as ascent and entry, for limited budget, spacecraft weight, volume, 
footprint, thermal control, power, communications bandwidth, and computer capacity. Resolution of 
higher risk issues in ascent, abort, entry, and landing can restrict margin and resources available to RPOD 
developers. This competition can place severe constraints on hardware choices and design margin during 
DDT&E. The ramifications of these choices can cascade through multiple systems impacting operations 
concepts and the ability to meet performance and mission requirements. 

During proximity operations and after docking/capture, spacecraft systems characteristics and integrated 
systems considerations become more significant in defining mission requirements and systems constraints. 
Systems design, operations concepts, and procedures for both vehicles should be examined for impacts and 
conflicts in the same manner as single vehicle systems. Parallel DDT&E of chaser and target vehicles in 
the Gemini, Apollo, Skylab, and Apollo/Soyuz Programs permitted early detection of systems and 
operations concepts conflicts, thereby lowering technical, cost, and schedule risk (Figures 7 and 8). The 
Space Shuttle performed rendezvous, proximity operations, and capture with many vehicles that were not 
designed to support servicing or capture by shuttle crew members (Figure 6). Asynchronous DDT&E, 
inadequate knowledge of target vehicle configuration, and an inability to perform integrated systems tests 
and capture hardware fit checks, resulted in capture problems on several shuttle missions that were not 
detected until the missions were flown. However, alternate methods using the Remote Manipulator System 
or the gloved hands of EVA crew members were used to successfully perform capture. 




§ 

Figure 7 Gemini and Agena testing Figure 8 July 1974 fit check of the 

before Gemini 6 (September 1965). APAS 75 docking hardware for 

Apollo/Soyuz. 

Integrating Legacy Hardware, Procedural Work-Arounds, and Simple Tools 

Cost, schedule, and vehicle margin challenges, such as weight growth and demands for increased capability 
in thermal control, propulsion, power, and communications during the DDT&E phase, may drive program 
management to seek alternatives to proposed hardware and operations concepts. These alternatives 
include, but may not be limited to, the use of legacy hardware, operations concepts, and piloting tools from 
previous flight programs. 

Examining the requirements and design differences between spacecraft under development and legacy 
spacecraft can help identify areas that may represent cost, schedule, and technical risk. These differences 
are also keys to understanding why some legacy hardware and operations concepts are not appropriate for 
a new vehicle. For example, the Space Shuttle has much larger RCS jets than Gemini and Apollo 
spacecraft, and Space Shuttle rendezvous targets were more sensitive to RCS jet plume impingement. 
Orion and Altair have automated rendezvous and docking requirements, while the Gemini, Apollo, and 
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Space Shuttle vehicles did not. Orion uses solar cells for power generation, while previous NASA human 
spacecraft used fuel cells during RPOD. 

Flight proven, legacy hardware may not meet requirements for the program under consideration. 
Furthermore, obsolescence and parts availability issues and associated costs, may make the use of legacy 
hardware prohibitive. Adoption of legacy RPOD operations concepts may be of value for reducing 
DDT&E risk, but may not enable a vehicle to meet new programmatic and systems requirements for 
RPOD. However, many best practices from legacy programs can be implemented to reduce risk to mission 
success. 

Constraints imposed on RPOD activities by RPOD and non-RPOD systems and programmatic resource 
limitations may be overcome with procedural work-arounds to avoid hardware and software modifications. 
While this saves money in the near term, long term life cycle and per mission costs may increase. A 
spacecraft with little or no margin and redundancy in RPOD and non-RPOD systems may be attractive for 
lowering DDT&E costs, but will have a higher risk of mission failure. 

Although the use of manual procedural work-arounds may be intensive in terms of procedures 
development, crew training, and contingency analysis, it provides simple, robust, and fault tolerant 
operations. Operational work-arounds have been preferred for the Gemini, Apollo, and Space Shuttle 
vehicles over hardware and software development and modification to save time, budget, and resources. 
While the Shuttle has been very successful in rendezvous and proximity operations, this philosophy has 
resulted in the development of continuously evolving contingency procedures that require extensive pre- 
flight simulation and analysis. These on-board and ground procedures are labor intensive and additional 
training for crew and ground personnel is required. 

Crews of the Gemini, Apollo, and Space Shuttle vehicles used 
simple tools to maintain relative motion situational awareness. 

Simple tools are lower mass, volume, power, cost, and risk 
alternatives to application of hardware with more advanced 
technology. These tools often took advantage of sub-systems that 
were already on the vehicles, such as cameras. Acetate overlays 
placed on Space Shuttle closed circuit television camera screens 
have proven to be reliable and effective at providing crews with 
range data (Figure 9). However, unlike the Shuttle, the future 
Orion and Altair vehicles will not be equipped with a camera that 
provides an orthogonal view of the docking mechanisms. 

The Crew Optical Alignment Sight (COAS, Figure 10), flown on 
the Apollo CSM, Apollo LM, and Space Shuttle has proven to be 
an effective tool for pointing the vehicles during proximity 
operations and as a backup method of pointing during bum 
execution and IMU alignment. COAS subtended angles are a 
backup method of range determination during proximity 
operations. However, the ability to derive range from subtended 
angles is dependent on the target maintaining a desired attitude, 
and orbital lighting conditions. Furthermore, range determination 
.using subtended angles can only be performed at relatively close ranges, and is not accurate enough to 
meet capture envelope requirements for successful docking. A timer to manually compute range rate from 
subtended angle range measurements over a time interval has proven to be a simple and effective tool for 
manual proximity operations piloting. 

Changes in mission requirements and performance limitations not apparent during the DDT&E phase may 
require that additional hardware, software, and tools be added to a vehicle. The original 1970s era shuttle 
rendezvous architecture was designed for an operations concept that included the same high energy inertial 
final approaches to the target that were flown during Gemini and Apollo. However, new final approach 
techniques were developed for shuttle proximity operations that did not subject targets to the high level of 
RCS jet plume impingement inherent with the legacy Gemini and Apollo final approach. To enable the 
crew to more effectively fly these techniques, maintain situational awareness, and reduce propellant 



Figure 9 Space Shuttle camera 
ranging ruler overlay for use 
during docking with the ISS. 
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Figure 10 COAS (left) and subtended angles range chart (right) from STS-39 (April-May 1991). 

consumption, new proximity operations sensors and new piloting software were added to the shuttle. 
These tools were the Rendezvous and Proximity Operations Program (RPOP) software, the Trajectory 
Control Sensor (TCS) lidar, and the Hand Held Lidar (HHL ). 3 " 5 To reduce costs, these new tools were not 
integrated into the baseline, certified avionics system. They were also not certified to the same level of 
criticality as the baseline avionics. The legacy rendezvous radar backup techniques, using simple tools, 
continued to be available in the event of software or sensor failures. 


Simple tools are useful as backup during manual piloting or for cross-checking the performance of 
automated piloting. However, simple tools are not a replacement for more robust and capable relative 
sensors. The use of simple tools and any associated procedures and mathematical calculations, such as 
computing range rate by hand, can increase the number of tasks performed by the crew. Operational 
workarounds, either complex and labor intensive or straightforward, and simple tools can be used to avoid 
short term hardware and software procurement and modification costs. However, they are not an option if 
automation, autonomy, and limited crew size requirements are to be met. 


CHASER AND TARGET VEHICLE INTEGRATION 

Chaser and target spacecraft must be considered an integrated system even before docking or capture 
occurs. Spacecraft systems not directly concerned with rendezvous and proximity operations can affect 
planning and operations concepts. Non-rendezvous or generic target system constraints might drive 
requirements on the chaser systems and trajectory. Shuttle and target non-rendezvous systems are 
examined for impacts to rendezvous, proximity operations, and capture. 

Personnel designing a chaser spacecraft actively investigate the suitability of systems on the target 
spacecraft that are desired for use by the chaser, such as power, communications, or thermal control. Use 
of systems on both vehicles during RPOD requires early coordination between systems owners and 
operations concept developers. Target spacecraft systems may require modifications to support the chaser. 
The chaser program will have to initiate negotiations with the target spacecraft owner to use the systems in 
question. 

Target and chaser vehicle owners need insight into each other’s systems and must understand the roles 
played by various agencies and contractor organizations to ensure mission success and manage risk. 
Chaser spacecraft designers may not understand the role the target vehicle owner plays in managing risk 
and ensuring safety. There is a legitimate need for the target vehicle owner to have insight into chaser 
vehicle systems design and operation. This insight is necessary when coordinating chaser and target 
vehicle timelines for configuration of vehicle systems for docking or capture. In addition, systems insight 
is required for the development of contingency procedures. 
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Table 1 

Vehicles That Dock With The ISS 


Type 

Vehicle 

Year 

2008 

2009 A 

2010 A 

Human 

Missions 

Space Shuttle 

4 

5 

3 

Soyuz 

2 

4 

4 

Robotic 

Missions 

Progress 

4 

6 

5 

ATV 

1 


1 

HTV 


1 

1 

COTS 


1 

1 


A Planned and subject to change. 



TPI 


Figure 11 Orion proximity operations relative motion 
is constrained by the Approach Ellipsoid and Keep Out 
Sphere. 


Four vehicles currently dock with the ISS (Table 1). These are the Space Shuttle, Soyuz, Progress, and the 
Automated Transfer Vehicle (ATV). In the future the H-II Transfer Vehicle (HTV), Orion, and 
Commercial Orbital Transportation Services (COTS) vehicles will dock with the ISS as well. Missions to 
the ISS, from multiple space agencies, present NASA with a complex integration task. Differing cultures, 
languages, and preferred vehicle design and operations best practices of ISS international partners further 
complicates ISS mission integration. In addition, export control regulations place restrictions on 
information exchange between international partners. 


The integration task includes ensuring that vehicle missions and systems requirements are compatible with 
the ISS, and that vehicle systems will enable safe and successful proximity operations under a variety of 
performance conditions. To ensure safety during proximity operations with automated and robotic 
vehicles the ISS Program has defined volumes of space around the ISS known as the Approach Ellipsoid 
and the Keep-Out-Sphere. Specific requirements have been defined governing when visiting vehicles 
(ATV, HTV, Orion, and COTS) may enter these volumes and what relative motion under nominal and off- 
nominal conditions is acceptable (Figure 11). 


Maintenance of ISS orbital altitude must be performed to provide launch windows for these vehicles, as 
well as to avoid orbital debris and counter-act orbital decay due to atmospheric drag. Propulsion systems of 
docked spacecraft, such as the Space Shuttle, ATV, and Progress may be used for orbit raising maneuvers. 


Analysis of attitude control of the mated stack after docking is performed. This requires a detailed 
understanding of attitude control systems on both vehicles. Of particular importance is the comprehension 
of the failure safe modes for both spacecraft. These failure and safe modes impact planning for 
contingency procedures for the proximity operations phase. The impact on RPOD of systems and 
component failures on either spacecraft must be investigated and data to be exchanged and spacecraft- to- 
spacecraft commanding capabilities during RPOD defined. Items to be negotiated include safe approach 
and departure trajectories, permission to enter volumes of space surrounding the target spacecraft to 
perform final approach, use of target systems for relative navigation, and data transfer (including systems 
status) between vehicles and flight control centers. 


Thermal issues on a spacecraft can restrict attitudes that can be flown. This in turn can limit relative 
navigation sensor activities. Inadequacies in these systems will result in thermal problems, thermal related 
mission constraints, and delays in gaining access to a spacecraft after mating. Chaser and target vehicle 
power generation constraints can also restrict available spacecraft attitudes. 


Non-rendezvous systems impacts can include, but are not limited to: systems used by both vehicles while 
mated, space-to-space communications links under nominal and off-nominal scenarios, availability of 
ground or satellite communications links, solar array visibility to the sun, radio-frequency hazards that 
create antennae pointing constraints, gaseous or liquid vents and dumps, thermal control; and spacecraft 
orientation requirements during free or mated flight due to concerns with plume impingement 
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(contamination, static and dynamic loads, thermal), attitude control, antennae or sensor visibility, and 
structural clearance. Plume impingement concerns for solar arrays or radiators may force deactivation of 
some RCS jets used during approach and capture. 

Spacecraft operations concepts may assume that on-board and ground software will no longer be modified 
once a vehicle is operational. Experience from past programs indicates that ground and on-board software 
will evolve throughout a program, particularly on-board software associated with flight control, capture 
mechanisms, and robotics. Impacts of software changes and hardware upgrades on chaser and target 
vehicles and supporting ground systems must be assessed. 


VEHICLE DESIGN 

Development and operational challenges in the more safety critical areas of ascent and entry may limit the 
remaining resources devoted to developing and certifying rendezvous and proximity operations capabilities. 
The Space Shuttle was not optimally designed for rendezvous and proximity operations. Mission plans, 
procedures and additional hardware and software were developed to permit accomplishment of various 
missions, but with higher operational costs and complexity. A vehicle with limited systems to support 
RPOD can still perform RPOD missions through creative mission planning and procedural development. 
However, limited RPOD capability can result in more operational complexity, increased life cycle costs, 
and increased risk to mission success. 

Redundancy in both rendezvous/proximity operations systems and non-rendezvous/proximity operations 
systems raise the probability of mission success in the presence of systems failures or dispersed trajectories. 
Generic system redundancy can lower the probability of a generic system issue affecting rendezvous or 
proximity operations. A “minimalist” design, meaning non-redundant systems and limited systems 
capability, may be perceived to be attractive from the standpoint of reducing development and operations 
costs. However, such a vehicle has a high risk of mission failure and may even have risks associated with 
flying a nominal mission with expected dispersions. Low levels of redundancy and minimal system 
performance margins complicate mission planning and increase life cycle costs. 

Accounting for servicing and assembly considerations will impact vehicle design. Whether a vehicle is 
envisioned for robotic-only interaction or human EVA interaction, these capabilities will drive the design of 
many aspects of the vehicle. This is true even for systems that are seemingly unrelated to servicing and 
assembly, such as electrical systems, thermal control, and avionics. Systems normally thought of as being 
uninvolved with servicing will be forced to accommodate issues such as mass limitations, volume 
constraints, contamination potentials, etc. Therefore servicing capability imposes requirements upon 
vehicle design. The importance of including EVA, robotics, and RPOD operational expertise from the 
onset of the design process cannot be over-emphasized . 6 


INTEGRATING RENDEZVOUS AND PROXIMITY OPERATIONS SYSTEMS 

Selection, design, integration, and operation of systems that perform specific rendezvous and proximity 
operations tasks require a thorough understanding of mission requirements. These systems may primarily 
be located on the chaser or may exist at varying levels of integration on both the chaser and target vehicles. 
Division of rendezvous/proximity operations systems and tasks between the spacecraft is an important 
consideration. A target may only possess mating hardware compatible with the chaser or, at the other 
extreme, may perform rendezvous maneuvers in coordination with the chaser and have active relative 
navigation sensors of its own. 

Use of only ground radar measurements for chaser spacecraft orbit determination constrains maneuvers to 
be planned around periods of chaser visibility to ground tracking stations. Such opportunities may not occur 
on every orbit. The use of space based tracking, such as TDRSS or GPS, in conjunction satellite 
communications, removes this constraint and permits more flexible mission planning. 

Relative navigation sensors may drive requirements for other systems. Those systems involving radio- 
frequency transmission may have restrictions due to radiation exposure limits of other systems on the 
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chaser, target, or even astronauts. Radio-frequency reception may be affected by multi-path from the chaser 
and target structure and may require steps to minimize multi-path, such as solar array feathering. Attitude 
requirements may also be driven by the systems. 

Relative navigation sensor placement for minimizing the heat path during entry and landing may degrade 
sensor performance. Not minimizing the heat path may prevent sensor re-use on a later mission. Significant 
maintenance may have to be performed to return the sensor to a flight worthy condition. Mass and volume 
constraints will also drive the selection of relative sensors. The type and level of redundancy may drive a 
need for more complex software algorithms to support redundancy management. 

Relative sensors may also support multiple applications. The Apollo CSM sextant was used for IMU 
alignment, cis-lunar navigation, lunar landmark tracking, and relative navigation during rendezvous. The 
Space Shuttle star trackers are used for IMU alignment and relative navigation. The Space Shuttle 
rendezvous radar antenna is also used for communication with the TDRSS satellites. Multiple uses for 
hardware can reduce mass, volume, and development costs. This will require coordination between 
multiple systems owners to ensure that performance requirements will be adequate and that conflicting 
operations requirements do not compromise the ability of the spacecraft to meet mission objectives. 

Priorities and procedures for shared use of sensors and other RPOD systems must be coordinated to permit 
successful operations. Sharing sensors between applications can also complicate spacecraft system 
upgrades after the flight phase of a program has begun. A communications system may provide critical 
measurements for relative navigation, and may support vehicle inspection or public affairs as well. 
Cameras may be used for several tasks that may have conflicting requirements. Optimal placement of 
cameras to support a task, such as an EVA, may not be optimal to support proximity operations piloting. 

Propulsion system design may be driven by factors that have higher priority and more criticality than 
RPOD considerations. These include control authority during ascent and entry, as well as plume self- 
impingement on solar arrays and other spacecraft structure. Propulsion system design that is not optimal 
for RPOD can result in plume impingement on target spacecraft, cross coupling, excessive propellant 
consumption, lengthy bums, thermal constraints on RCS jet operation, insufficient control authority, and 
insufficient redundancy. Plume impingement can result in undesirable target spacecraft rotation and 
translation that the target spacecraft may not be able to counteract. This can result in compromise of 
stmctural integrity and contamination of sensors and scientific payloads. Procedural work-arounds to 
overcome these issues will complicate mission planning, risk management, and increase life cycle costs. 


CONTINGENCY PLANNING 

Space flight, robotic or human, is expensive, high risk, and highly visible to government leaders, the news 
media, and the public. Systems or performance anomalies may arise that can limit the ability of the 
spacecraft and crew to accomplish mission objectives. Mission failures, catastrophic or non-catastrophic, 
negatively affect users of spacecraft services and complicate the budget process. Designing spacecraft 
systems architecture and associated operations concepts to handle contingencies is a complex integration 
task. 7 

The overall rendezvous phase of a mission may vary in length from hours to days. During this time 
numerous issues may arise that require complicated, time consuming, and coordinated crew and Mission 
Control responses to ensure that mission objectives will still be met. More time is available during 
rendezvous to conduct anomaly investigations and formulate and implement work-arounds. This can 
complicate automation and autonomy considerations for contingencies. In contrast, ascent (-11.5 minutes 
for an Apollo Saturn V, -8.5 minutes for the Space Shuttle) and re-entry (-14 minutes for an Apollo lunar 
mission, -30 minutes for the Space Shuttle) are much shorter. Responses to performance anomalies during 
ascent and entry are more scripted than during on-orbit. 

Non-catastrophic systems and dynamics issues can arise on-orbit, that could prevent successful completion 
of a mission or limit the time available for on-orbit activities (Table 2). While some types of system 
anomalies can be postulated during ground analysis pre-mission, other anomalies that can occur during a 


10 



Table 2 

Anomalies That Can Occur During RPOD Missions 


• degraded camera performance due to extreme 
variation in orbital lighting conditions 

• misalignments due to uneven thermal gradients 
across work surfaces 

• bent pins from mating or demating of electrical 
connectors 

• failed mating attempts that induce multi-axis 
rates 

• RCS jet or other propulsion system failures 

• degradation of materials on-orbit 


• optical sensor contamination 

• capture hardware anomalies 

• communications difficulty 

• thermal control problems 

• artificial lighting failures 

• trajectory perturbations 

• power system failures 

• fluid coupler leaks 

• stuck fasteners 

• sensor failures 


mission cannot be as easily postulated. Systems anomalies can cause performance degradations that 
cascade throughout multiple spacecraft systems.** 


The level of operational flexibility of a spacecraft and ground support system will determine the ability to 
respond to unanticipated failures. A program should assess the criticality of vehicle operations and 
determine how much preparation is required to handle in-flight anomalies. Ensuring the success and safety 
of high risk, high profile space flight operations such as the Space Shuttle and ISS requires planning for 
contingency operations and work-arounds to protect against systems failures. Contingency planning 
requires participation of personnel from any number of chaser and target vehicle disciplines. However, 
other programs, such as robotic vehicles, may be willing to accept a higher risk of mission failure and may 
not have to go to such extraordinary lengths to ensure mission success. 


For example, Shuttle ascent propulsion problems (such as an early main engine shutdown) may limit the 
ability of the Shuttle to fly the planned rendezvous profile to the ISS. Contingency plans, coordinated with 
the Russians, have been developed for the ISS to lower its orbit to accommodate a revised Shuttle 
rendezvous profile. 9 Numerous CSM or LM active rendezvous contingency plans were developed for the 
Apollo lunar missions in the event of LM performance problems that prevented execution of the nominal 
rendezvous profile. 


Hardware or software anomalies on either spacecraft could force development of alternative procedures 
before launch or at any time during flight. 7 The impact of an anomaly is assessed before implementing a 
fix or procedural work-around. The impact may be less than initially thought, and a proposed fix or work- 
around could have worse implications than the original anomaly. 


APPLYING LESSONS LEARNED TO RPOD INTEGRATION 

Mitigating cost, schedule, and technical risk is facilitated by studying lessons learned and experiences of 
legacy programs. 8 Of particular interest are the challenges that were encountered during the DDT&E and 
flight phases, and how these challenges were eventually overcome. Two of the four examples in this 
section, late addition of VHF ranging to the Apollo CSM and Space Shuttle plume impingement, highlight 
the importance of early and thorough evaluation of vehicle design impacts on RPOD performance. Early 
identification of design issues that may prevent the spacecraft to meet performance requirements should be 
made to permit resolution of the issues during the DDT&E phase. 

Late Addition of VHF Ranging To the Apollo CSM 

Most spacecraft development programs undergo requirements and vehicle design scrubs to improve 
margins in areas such as weight, thermal control, and software. However, it is important to ensure that 
vehicle systems will still possess sufficient performance to meet requirements after the scrub is completed. 

The original CSM design included a rendezvous radar to support contingency CSM active rendezvous with 
a disabled LM in lunar orbit. However, the CSM radar was deleted in the fall of 1964 during a weight 
reduction effort. Alternate means of obtaining range measurements were studied, such as modification of 

Reference 8, Lessons Learned From Seven Space Shuttle Missions , contains examples of the use of contingency procedures and 
the unanticipated impacts of performance degradation through multiple systems. 
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the CSM/LM Very High Frequency (VHF) communications system. However, at the time it was believed 
that the use of only the line-of-sight angle measurements provided by the CSM sextant was sufficient to 
support contingency CSM rendezvous with the LM. By the summer of 1967, studies revealed that the 
CSM pilot did not have enough time to acquire a sufficient number of sextant marks. In addition, an 
insufficient amount of propellant was available to support sextant only relative navigation. Ground tracking 
was not considered a viable alternative due to unexplained perturbations in Lunar Orbiter spacecraft 
tracking data, later identified to be the result of lunar mass concentrations. Several means of obtaining 
relative range measurements were studied. In September 1967, the Apollo Program issued direction for the 
modification of the CSM VHF communications system to supply range, and modification of the Entry 
Monitoring Subsystem to display range data to the CSM pilot. VHF ranging was first flown on the Apollo 
10 (May 1969) mission to the Moon. 

Late Recognition of Space Shuttle Plume Impingement 

It is particularly important to research and understand the impact of new vehicle design characteristics on 
performance. An example of this is the Space Shuttle plume impingement issue. From March through June 
of 1973, a total of 491 human-in-the-loop simulations were conducted to evaluate Space Shuttle docking 
with a notional space station. The objective was to determine if any changes to the Preliminary 
Requirements Review (October 1972) baseline orbiter design were required in the areas listed in Table 3. 

Based on the study, many recommendations were made concerning docking contact conditions, crew 
displays, crew station arrangement, cameras, stand-off cross targets, sensor data, target vehicle attitude 
control, orbiter flight control modes, RCS jet selection, propellant consumption, and cross coupling. The 
study concluded that more simulations were needed to take into account changing orbiter systems 
configuration during the DDT&E phase so that docking requirements could be more precisely and 
realistically defined. 

Also in 1973 shuttle RPOD personnel became concerned about the 
possibility of RCS jet plume impingement contamination of target 
spacecraft and associated scientific payloads and other sub-systems. 1 
The size of the orbiter RCS jets was much larger than the Gemini and 
Apollo jets. However, the implications of plume impingement on RCS 
system design were not examined in the 1973 docking simulation effort 
(Table 3). Plume impingement math models for simulations did not 
become available until 1976. 

By April of 1977 the concern about plume impingement impact on the 
ability of the shuttle to meet basic requirements for rendezvous with 
and retrieval of satellites was receiving attention from upper level 
program management. This occurred after completion of much of the 
DDT&E phase, and well after the February 1975 shuttle Critical Design 
Review. Not only was contamination of target vehicle systems a 
concern, but plume induced target rotational and translational motion 
could prevent shuttle crew members from grappling the target using the 
Remote Manipulator System. Methods of attitude control of some 
target spacecraft may not have been able to counteract the effects of 
plume induced dynamics. 

A considerable effort was undertaken by the Shuttle Program to develop new trajectory and piloting 
techniques and to identify potential shuttle hardware and software modifications to overcome the plume 
impingement issue. New piloting and trajectory techniques were developed as part of the newly defined 
“proximity operations” phase of rendezvous. The orbiter flight control system software was modified to 
perform braking with a set of RCS jets that lowered the risk of plume impingement. A local vertical local 
horizontal attitude hold mode was also added. Shuttle hardware modifications and associated DDT&E 
impacts were avoided. The development and verification of custom proximity operations trajectories and 
piloting techniques, for most shuttle missions involving RPOD, increased mission operations life cycle 
costs over the life of the Shuttle Program. While the 1973 docking study examined many important areas 
of vehicle performance (Table 3), it was another four years before the plume impingement issue and the 
negative impact on shuttle RPOD performance was fully understood at higher levels in the Shuttle Program. 
This recognition came too late to influence vehicle design. 


Table 3 

Topics Examined During 1973 
Space Shuttle Docking Study 

• Maneuver rates 

• Required minimum impulse 
for translation and rotation 

• Flight control requirements 

• Attitude hold requirements 

• Effects of control modes on 
center of gravity variations 

• Target motion 

• Hand controller location and 
logic 

• Reduced RCS thrust levels 

• Target displays 

• Range, range rate, and 
attitude display requirements 

• Station-keeping 

• Docking contact criteria 

• RCS propellant requirements 
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Balancing Automation, Autonomy, and Authority 

Automation, autonomy, and the authority of crew and ground personnel to control spacecraft operation are 
important aspects of spacecraft and operations concept design. Automation is the ability of the vehicle to 
operate without human control and intervention, but the crew or ground may serve in an oversight role and 
provide input and control if required. Autonomy is the ability of a vehicle to perform a function without 
external support. For a human spacecraft autonomy is not limited to on-board systems, but also includes 
troubleshooting and decision making activities by crew members. Authority is the ability of the crew and 
ground personnel to exercise control of vehicle systems under both nominal conditions and off-nominal 
conditions caused by performance anomalies or failures. 2 tt 

The level of automation or autonomy and division of tasks between the crew, onboard flight computer, and 
Mission Control varies based on the flight phase and complexity of the tasks. An appropriate balance 
between crew and ground authority, spacecraft automation, and spacecraft autonomy is required to ensure 
mission success, safety of flight, and to lower risk to cost and schedule during the vehicle development 
phase. However, the appropriate balance is not necessarily the same for all vehicles and missions. 

The 2007 Orbital Express mission was a technology demonstration of autonomous and automated robotic 
serving, rendezvous, and proximity operations. However, attitude control, computer, and sensor issues 
arose that threatened the success of the mission. Orbital Express ground personnel had enough authority to 
re-plan the mission, correct software problems, and implement procedural work-arounds to address the 
performance issues. In spite of the problems encountered during the mission, Orbital Express 
accomplished objectives for autonomous and automated rendezvous, proximity operations, and robotic 
servicing. Orbital Express is a good example of a mission that had an appropriate balance of automation, 
autonomy, and authority. 10 

By the 1980s the Russians regularly performed automated rendezvous and docking with the Salyut space 
stations, although manual dockings were occasionally performed in response to systems anomalies during 
proximity operations. During the Soyuz T-8 mission to dock with Salyut 7 in April of 1983, the on-board 
Igla system did not supply relative measurements required to support either automated or manual 
rendezvous and docking. In spite of the lack of relative sensor data, the plan was for the crew to fly 
proximity operations and docking using only the periscope and verbal piloting cues provided by flight 
controllers on the ground. While ground-based precision orbit determination placed Soyuz T-8 within 1 
kilometer of Salyut 7, the crew was not able to sufficiently control relative motion to achieve a safe final 
approach and docking. The next mission, Soyuz T-9, successfully docked with Salyut 7. 11 

In June of 1985 the Soyuz T-13 spacecraft was launched in an attempt to dock with and reactivate the 
Salyut 7 space station after a loss of telemetry. Like the Soyuz T-8 mission, data from the Igla sensors 
were not available to support either automated or manual rendezvous and docking. Nor was Salyut 7 able 
to control attitude to support the docking. However, precision orbit determination by Russian Mission 
Control, improved manual piloting training, and the use of a laser rangefinder and night vision device by 
the crew enabled the Soyuz T-13 to successfully dock with Salyut 7. The crew later returned Salyut 7 to an 
operational configuration. Additional manual approaches to Salyut 7 were flown by the Soyuz T-13 crew 
at the end of the 3 month mission to further evaluate manual approaches. 

In 1986 the Russians began flying the upgraded Soyuz TM spacecraft. The automated rendezvous and 
docking capability was improved with the Kurs system replacing Igla. Manual piloting was improved as 
well. A forward looking window was added to the Soyuz orbital module to improve situational awareness 
beyond that provided by the periscope. A second set of translational and rotational hand controllers was 
added to the orbital module as well. A laser rangefinder and a night vision device also became standard 
equipment. 11 The current Soyuz TMA is similarly equipped. 

In summary, the Russians upgraded both the automated and back-up manual piloting systems for Soyuz. 
These upgrades, along with expanded crew training, resulted in a balance of automation, autonomy, and 
authority that could better ensure mission success in the presence of system failures. 


ft Reference 2, “Challenges of Orion Rendezvous Development,” contains a more detailed discussion of automation, autonomy, and 
authority. The appendix of the paper describes the levels of automation in the Mercury, Gemini, Apollo, Space Shuttle, and Orion 
vehicles. 
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Sensor Risk Reduction Through Flight Testing 

NASA personnel studied the lessons learned and 
experiences of several flight programs with relative 
navigation sensors. Experience has shown that it is 
difficult for a ground test facility to duplicate all aspects 
of the space environment that impact relative sensor 
performance. On-orbit testing may be required in 
addition to ground testing, to subject new hardware and 
software to a wider range of flight conditions than can be 
performed on the ground. As a result NASA has 
proposed a test of Orion RPOD sensors on the STS- 133 
Space Shuttle Mission to the ISS (Figure 12). The test 
would fly part of the Orion rendezvous and proximity 
operations profile after the orbiter has separated from the 
ISS. 

INTEGRATED TEAMS 

The successful integration of new and legacy technology and development of spacecraft systems, 
operations concepts, mission plans, and successful execution of a mission depends on team work. The 
contribution of integrated teams to the technical success of a flight program applies to both human and 
robotic spacecraft. The success of RPOD development and operations in the Gemini, Apollo, Skylab, 
Apollo- Soyuz, Space Shuttle, and ISS Programs was in part due to the existence of integrated teams. 
Personnel freely communicated across corporate and civil servant/contractor boundaries in a badge-less, 
collaborative work environment. In addition, the participation of other nations in a flight program, such as 
the ISS, requires open communication and team work across cultural and language barriers. 

Open communication of technical details between development and operations personnel was conducted 
on these programs, and is essential to mitigate risk. Availability of requirements, source code, and details 
of technical issues to all participants for a variety of on-board and ground systems led to widespread 
understanding of system requirements and technical difficulties. Software requirements and source code 
were custom developed for space flight and were not proprietary. Comparisons of simulation data among 
civil servant and contractor organizations helped debug simulation software and led to rapid identification 
and resolution of performance issues and avoided problems that required re-work to be performed. 

Team work and development of an integrated crew timeline is an important factor in the successful 
execution of RPOD, servicing, and assembly tasks by astronauts. Rendezvous and proximity operations 
tasks may not be the only activities performed by a crew. This is particularly true of the Space Shuttle 
(Table 4). Most Shuttle missions also fly multiple secondary payloads. These payloads are lower in 
priority than the primary payload, but have the same priority relative to each other in terms of requirements 
for crew time and spacecraft resources such as thermal control, communications bandwidth, and power. 
Tasks associated with the primary payload and secondary payloads are often worked by crew members in 
parallel with RPOD preparation and procedure execution. Some shuttle missions performed dual shift 
crew operations during RPOD, as depicted in Figure 13 from the STS-66 mission. Integration of 
secondary payload and house-keeping tasks, RPOD tasks, available crew time, and resource requirements 
such as attitude, over flight of ground stations, or maneuvers during crew sleep periods must be 
coordinated before and during the flight. 

During servicing or assembly, the concept of an “EVA mission within a space mission” dictates the need 
for the crew and ground personnel to function as a highly integrated team during RPOD, servicing, and 
assembly hardware development, pre-flight planning, and real-time mission execution. Independent 
timelines for servicing or assembly are performed within the overall mission timeline. Crew members and 
teams on the ground must concurrently manage proximity operations piloting, space suit life support 
systems operational verification/activation, EMU donning by crew members, EVA tools 
assembly/checkout, robotics systems activation and checkout, plus in-suit pre-breathing for decompression 
sickness prevention. These tasks would be impossible without interdisciplinary coordination and 
communication. 



Figure 12 One of several proposed profiles 
for a Space Shuttle test of Orion sensors. 
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Table 4 

Major Shuttle Crew Activities During ISS Rendezvous 


Flight Day 1 

Flight Day 2 

Flight Day 3 

• Crew Wakeup at KSC 

• Post-Sleep Activities 

• Post-Sleep Activities 

• Suit Up 

• OBSS Unberth 

• Maneuvers & Piloting 

• Travel to Launch Pad 

• Starboard TPS Survey 

• Docking 

• Crew Ingress 

• EMU Checkout 

• Leak Check 

• Launch and Ascent 

• Nose and Port TPS Survey 

• Hatch Opening 

• Post Insertion Activities 

• OBSS Berth 

• Safety Briefing 

• Cockpit Setup 

• Maneuvers 

• OBSS Unberth 

• Maneuvers 

• Docking System Checkout 

• OBSS H/O to RMS 

• RMS Checkout 

• Rendezvous Tools Checkout 

• Pre-Sleep Activities 

• Pre-Sleep Activities 

• Pre-Sleep Activities 

• Sleep 

• Sleep 

• Sleep 



EMU - Extra Vehicular Mobility Unit, H/O - Hand Over, KSC - Kennedy Space Center, OBSS - Orbiter Boom 
Survey System, RMS - Remote Manipulator System 
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Figure 13 Crew timeline for the CRISTA-SPAS rendezvous and grapple on STS-66 (November 1994). 
Note the dual shift (RED and BLUE) crew operations, rendezvous maneuvers (NC15, NH, etc.) during 
crew sleep, and grapple with both shifts awake. 


RPOD, EVA, robotics, and other personnel at Mission Control and other ground locations must function in 
multiple roles. They are, first and foremost, working as part of the larger mission team. Any activity or 
issues arising with the chaser or target spacecraft must be monitored for impacts to the servicing and 
assembly objectives. Simultaneously, during execution of the proximity operations, EVA, and robotics 
timelines, the same personnel must monitor their own separate “spacecrafts.” These are the chaser, target, 
and EVA crew members. 


SUMMARY 

RPOD integration is a far more complex problem than treating propellant-optimal trajectories, relative 
sensors and navigation, and docking/capture mechanisms as separate, unrelated disciplines. The success of 
NASA human flight RPOD since 1965 is due to the coordination of system development, vehicle 
integration, and mission planning efforts of multiple, seemingly unrelated spacecraft and ground 
disciplines. Involvement of specialists outside of disciplines traditionally associated with rendezvous and 
proximity operations is required. These include not only specialists in EVA, robotics, and docking 
hardware, but extend to virtually every discipline associated with designing a vehicle and flying a mission. 

Early detection of performance issues and constraints requires a thorough understanding of mission 
requirements and involvement of knowledgeable personnel representing all spacecraft systems. Integrated 
requirements for both vehicles have to be defined and managed. This can become complex as it usually 
involves multiple contractors and government agencies. Many constraints on systems and operations 
concepts may not be discovered until after the DDT&E phase is well underway or even after flights have 
begun. Additional constraints may be discovered as mission requirements evolve or new requirements are 
introduced over the life of the flight program. 
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Integrated teams, open communication, detailed knowledge of spacecraft systems, and use of various types 
of simulations are required for effective mission planning, procedures development, and anomaly 
resolution. Sufficient consumables, systems redundancy, and control margins must exist to handle failure 
modes and off-nominal performance issues. These anomalies are unanticipated and, most assuredly, 
inevitable, and often cannot be anticipated for inclusion in pre-flight simulations. 

While current and future spaceflight programs will introduce new technologies and operations concepts, 
the complexity of integrating multiple systems on multiple spacecraft will remain. The RPOD systems 
integration task may become more difficult as increasingly complex software is used to meet automation, 
autonomy, and robotic operation requirements. 
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RPOD is often depicted as consisting 
of three unrelated disciplines: 


/ 


1 . Propellant-optimal trajectories 

2. Relative sensors and navigation 

3. Docking/capture mechanisms 




RPOD is systems integration: 




• absolute navigation 

• attitude control 

• automation 

• autonomy 

• avionics integration 

• command & data handling 

• communications 

• crew timeline 

• docking/capture hardware 

• extra vehicular activity 

• fault detection isolation 
reconfiguration 

• ground systems 

• human factors 

• lighting 

• logistics 


• orbital debris 

• plume impingement 

• power generation 

• procedures 

• propellant-optimal trajectories 

• propulsion 

• redundancy 

• relative navigation 

• robotics 

• sensors 

• servicing 

• software 

• structures 

• thermal control 

• export control 
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robotics 
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Propellant-optimal trajectories 


avionics integration 

command & data 
handling 


redundancy 

propulsion 

procedures 


Relative navigation and sensors 
Docking/capture mechanisms 


communications 

crew timeline 

extra vehicular 
activity 


power generation 

plume impingement 
orbital debris 

lighting 



human factors 


export control 

fault detection isolation 
reconfiguration 

ground systems 
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Examination of Requirements 
& Constraints 



RPOD and non-RPOD 
Sub-Systems 

The challenge of 
understanding 
evolving vehicle 
systems. 

Competition between 
flight phases. 
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Integrating Legacy Hardware, Procedural 
Work-Arounds, & Simple Tools 



Examining vehicle 
differences to identify 
risks. 

Alternatives to overcome 
cost, schedule, & 
performance margin 
challenges. 

Procedural work-arounds 
favored during DDT&E. 
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Legacy tools are robust but may not enable new 
vehicles to meet new requirements. 
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Chaser & target(s) are an integrated system. 


Chaser & target personnel 
need insight into each 
other’s systems. 

Integration covers RPOD 
& mated flight. 

Non-RPOD systems 
impacts can be mission 
planning, trajectory, & 
procedure drivers. 





Vehicle Design 

Competition with ascent & entry 

Resist the temptation to build 
a “minimalist” vehicle to lower 
DDT&E costs. 

Servicing and assembly must 
be considered. This includes 
robotics and EVA. 






Integrating RPOD Systems 



Requires thorough 
understanding 
of requirements. 

Division of tasks 
between vehicles. 

Multiple users of 
hardware. 

Priorities for shared 
use. 

Sensor placement. 






Propulsion design 
impacts. 
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Contingency Planning 

Space flight is high risk, high 
cost, and very visible. 

Anomalies WILL occur that 
require contingency 
procedures. 

More time available to work 
problems than ascent/entry. 

Many anomalies cannot be 
anticipated. 

Vehicle and ground flexibility 
is the key to overcoming 
anomalies. 
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Applying Lessons Learned to Integration 



Late recognition of Shuttle plume 
impingement. 


Balancing automation, autonomy, 
and authority. 

Autonomy 


Automation Authority 
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Successful integration of new and legacy 
technology depends on team work. 



Badge-less, collaborative work 
environment. 

Open communication. 

Close coordination between 
multiple disciplines during 
DDT&E, mission planning, 

& flight. 
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Summary 


Close cooperation across multiple 
disciplines, government agencies, 
& contractors. 

Early detection of performance 
issues & constraints. 

Detailed knowledge of systems, 
requirements, & emerging 
constraints. 

RPOD systems integration may 
become more complex with 
increasing level of automation 
& autonomy. 



Questions 
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